- 
                Notifications
    You must be signed in to change notification settings 
- Fork 421
Introduce Reply Paths for BOLT12 Invoice in Offers Flow. #3163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| Codecov ReportAttention: Patch coverage is  
 
 Additional details and impacted files@@            Coverage Diff             @@
##             main    #3163      +/-   ##
==========================================
+ Coverage   89.82%   90.39%   +0.57%     
==========================================
  Files         126      126              
  Lines      103024   108017    +4993     
  Branches   103024   108017    +4993     
==========================================
+ Hits        92543    97644    +5101     
- Misses       7769     7815      +46     
+ Partials     2712     2558     -154     ☔ View full report in Codecov by Sentry. | 
| Needs rebase now. | 
1a6175e    to
    eb0d3cc      
    Compare
  
    | Updated from pr3163.01 to pr3163.02 (diff): Changes: 
 | 
| Please include details about what you're doing and why in the commit messages. | 
| 
 Sorry about being lax when reviewing this. @shaavan I recommend this reference, which we mention in the project contributor guidelines: https://cbea.ms/git-commit/ | 
| I'm usually pretty lax as long as its clear from the code what's going on, but in this case I look at the commit and we're just adding a blinded path, which doesn't tell me anything about why. I have some context from a separate commit in a different PR, but I don't want to rely on that :) | 
eb0d3cc    to
    c2dd2fd      
    Compare
  
    | Updated from pr3163.02 to pr3163.03 (diff): Changes: 
 Thanks, @TheBlueMatt for the suggestion, and @jkczyz for the resource! | 
        
          
                lightning/src/ln/channelmanager.rs
              
                Outdated
          
        
      | match response { | ||
| Ok(invoice) => responder.respond(OffersMessage::Invoice(invoice)), | ||
| Ok(invoice) => { | ||
| let context = MessageContext::Offers(OffersContext::Unknown {}); | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are we actually gonna do with the InvoiceError now? This is for an inbound payment, presumably we'll just log and move on? Do we want to authenticate the BP at all? @jkczyz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'd figure we'd just log. What is "BP" refer to here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, blinded path. 😛 We could though maybe a lower log level is fine for now. Not sure how much we can do about sending another invoice without another request.
c2dd2fd    to
    890607e      
    Compare
  
    890607e    to
    bd171ee      
    Compare
  
    bd171ee    to
    213bafd      
    Compare
  
    213bafd    to
    f84a00e      
    Compare
  
    f84a00e    to
    e74642d      
    Compare
  
    When a InvoiceError is received for a sent BOLT12Invoice, the corresponding PaymentHash is to be logged. Introduce hmac construction and verification function for PaymentHash for this purpose.
e74642d    to
    2d794b5      
    Compare
  
    | Updated from pr3163.08 to pr3163.09 (diff): Changes: 
 | 
2d794b5    to
    c794bdd      
    Compare
  
    c794bdd    to
    e8b2409      
    Compare
  
    - The trait defines the public method one may define for creating and verifying the HMAC. - Using a pub trait to define these method allows the flexibility for other `OffersMessageHandler` construct to construct the HMAC and authenticate the message.
e8b2409    to
    e9a3e2c      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, feel free to squash.
Introduce HMAC and nonce calculation when sending Invoice with reply path, so that if we receive InvoiceError back for the corresponding Invoice we can verify the payment hash before logging it.
1. Introduced reply_path in BOLT12Invoices to address a gap in error handling. Previously, if a BOLT12Invoice sent in the offers flow generated an Invoice Error, the payer had no way to send this error back to the payee. 2. By adding a reply_path to the Invoice Message, the payer can now communicate any errors back to the payee, ensuring better error handling and communication within the offers flow.
1. Updated the Offers Test to check the reply paths in BOLT12 Invoices. 2. Changed the `extract_invoice` return type from `Option<BlindedMessagePath>` to `BlindedMessagePath` since all BOLT12Invoices now have a corresponding reply path by default.
e9a3e2c    to
    7b49993      
    Compare
  
    | Updated from pr3163.11 to pr3163.12 (diff): Changes: 
 | 
This PR builds on #3087 and addresses this comment.
Changes:
reply_pathwith the sentBOLT12Invoice.InvoiceErroralong thereply_path.reply_pathwherever applicable.